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Abstract 


This document describes how to use the Extensible Messaging and 
Presence Protocol (XMPP) to collect and distribute security incident 
reports and other security-relevant information between network- 
connected devices, primarily for the purpose of communication among 
Computer Security Incident Response Teams and associated entities. 

To illustrate the principles involved, this document describes such a 
usage for the Incident Object Description Exchange Format (IODEF). 
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Ly 


Introduction 


This document defines an architecture, i.e., "XMPP-Grid", as a method 
for using the Extensible Messaging and Presence Protocol (XMPP) 
[RFC6120] to collect and distribute security incident reports and 
other security-relevant information among network platforms, 
endpoints, and any other network-connected device, primarily for the 
purpose of communication among Computer Security Incident Response 
Teams and associated entities. In effect, this document specifies an 
Applicability Statement ([RFC2026], Section 3.2) that defines how to 
use XMPP for the exchange of security notifications on a controlled- 
access network among authorized entities. 


Among other things, XMPP provides a publish-subscribe service 
[XEP-0060] that acts as a broker, enabling control-plane functions by 
which entities can discover available information to be published or 
consumed. Although such information can take the form of any 


structured data (XML, JSON, etc.), this document illustrates the 
principles of XMPP-Grid with examples that use the Incident Object 
Description Exchange Format (IODEF) [RFC7970]. That is, while other 


security information formats can be shared using XMPP, this document 
uses IODEF as one such example format that can be published and 
consumed using XMPP. 


Terminology 


This document uses XMPP terminology defined in [RFC6120] and 
[XEP-0060]. Because the intended audience for this document is those 
who implement and deploy security reporting systems, mappings are 
provided for the benefit of XMPP developers and operators. 


Broker: A specific type of controller containing control-plane 
functions; as used here, the term refers to an XMPP publish- 
subscribe service. 


Broker Flow: A method by which security incident reports and other 
security-relevant information are published and consumed in a 
mediated fashion through a Broker. In this flow, the Broker 
handles authorization of Consumers and Providers to Topics, 
receives messages from Providers, and delivers published messages 
to Consumers. 


Consumer: An entity that contains functions to receive information 
from other components; as used here, the term refers to an XMPP 
publish-subscribe Subscriber. 
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Controller: A component containing control-plane functions that 
manage and facilitate information sharing or execute on security 
functions; as used here, the term refers to an XMPP server, which 
provides core message delivery [RFC6120] used by publish-subscribe 
entities. 


Node: The XMPP term for a Topic. 


Platform: Any entity that connects to the XMPP-Grid in order to 
publish or consume security-relevant information. 


Provider: An entity that contains functions to provide information 
to other components; as used here, the term refers to an XMPP 
publish-subscribe Publisher. 


Topic: A contextual information channel created on a Broker on which 
messages generated by a Provider are propagated in real time to 
one or more Consumers. Each Topic is limited to a specific type 
and format of security data (e.g., IODEF namespace) and provides 
an XMPP interface by which the data can be obtained. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 
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3. Architecture 


The following figure illustrates the architecture of XMPP-Grid. 


peepee Seaseeesee esas e be ess + 
| +-------------------------------------- + 
| | +-------------------------------------- + 
| | | | 
+- | Platforms 
+- 
a HH + 
/ \ / \ / \ 
/ c \ / \ / \ 
| |a| |a | a |B C 
[lel] i). 4 
DU AES Nm 25 te TE 
\ o / \ / 
\u d 37 \ / 
/ | --------------------- | \ 

/|----/ \-------- a |--|\ 
/ / Controller \. Gerd a \ 
\ \ & Broker / plane E / 

\ |----\ /-------- a |--|/ 

\ | --------------------- | / 
/ \ / \ 
Ï € X / \ 
| [n] [A | a |B C 
[lel] | | 
SS = epee 
ef \ / \ / 
\ 1/ \ / \ / 
F RR a es OAE + 
| | -+ 
| Platforms || 
| ee 
pose oo So SS Sa eee Se ke + | | 
pps Se es ee A E + | 
poset Se ee ee a ee + 


Figure 1: XMPP-Grid Architecture 


Platforms connect to the Controller (XMPP server) to authenticate and 
then establish appropriate authorizations to be a Provider or 
Consumer of topics of interest at the Broker. The control-plane 
messaging is established through XMPP and is shown as "A" (control- 
plane interface) in Figure 1. Authorized Platforms can then share 
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data either through the Broker (shown as "B" in Figure 1) or, in some 
cases, directly (shown as "C" in Figure 1). This document focuses 
primarily on the Broker Flow for information sharing ("direct flow" 
interactions can be used for specialized purposes, such as bulk data 
transfer, but methods for doing so are outside the scope of this 
document). 


4. Workflow 
Implementations of XMPP-Grid adhere to the following workflow: 


a. A Platform with a source of security data requests connection to 
the XMPP-Grid via a Controller. 


b. The Controller authenticates the Platform. 


c. The Platform establishes authorized privileges (e.g., privilege 
to publish and/or subscribe to one or more Topics) with a Broker. 


d. The Platform can publish security incident reports and other 
security-relevant information to a Topic, subscribe to a Topic, 
query a Topic, or perform any combination of these operations. 


e. A Provider unicasts its Topic updates to the Grid in real time 
through a Broker. The Broker handles replication and 
distribution of the Topic to Consumers. A Provider can publish 
the same or different data to multiple Topics. 


f. Any Platform on the Grid can subscribe to any Topic published to 
the Grid (as permitted by the authorization policy) and (as 
Consumers) will then receive a continual, real-time stream of 
updates from the Topics to which it is subscribed. 


The general workflow is summarized in the figure below. 
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XMPP-Grid implementations MUST adhere to the mandatory-to-implement 
and mandatory-to-negotiate features as defined in [RFC6120]. 
Similarly, implementations MUST implement the publish-subscribe 
extension [XEP-0060] to facilitate the asynchronous sharing of 
information. Implementations SHOULD implement Service Discovery as 
defined in [XEP-0030] to facilitate the means to dynamically discover 
the available information and namespaces (Topics) to be published or 
consumed. Care should be taken with implementations if their 
deployments allow for a large number of Topics. The result set 
management as defined in [XEP-0059] SHOULD be used to allow the 
requesting entity to explicitly request Service Discovery result sets 
to be returned in pages or a limited size, if the discovery results 
are larger in size. Note that the control plane may optionally also 
implement [XEP-0203] to facilitate delayed delivery of messages to 
the connected consumer as described in [XEP-0060]. Since information 
may be timely and sensitive, capability providers should communicate 
to the Controller whether its messages can be cached for delayed 
delivery during configuration; such a function is out of scope for 
this document. 


The following sections provide protocol examples for the service 
discovery and publish-subscribe parts of the workflow. 


5. Service Discovery 


Using the XMPP service discovery extension [XEP-0030], a Controller 
enables Platforms to discover what information can be consumed 
through the Broker and at which Topics. Platforms could use 
[XEP-0059] to restrict the size of the result sets the Controller 
returns in a Service Discovery response. As an example, the 
Controller at ‘’security-grid.example’ might provide a Broker at 
'broker.security-grid.example’, which hosts a number of Topics. A 
Platform at ‘’xmpp-grid-client@mile-host.example’ would query the 
Broker about its available Topics by sending an XMPP "disco#items" 
request to the Broker: 


<iq type=’ get’ 
from=’ xmpp-grid-client@mile-host.example/2EBE702A97D6’ 
to=’broker.security-grid.example’ 
id=’ B3C17F7B-B9EF-4ABA-BO8D-805DA9F34626’ > 
<query xmlns='http://jabber.org/protocol/disco#items’ /> 
</iq> 
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The Broker responds with the Topics it hosts: 


<iq type=' result’ 
from=' broker.security-grid.example' 
to=’ xmpp-grid-client@mile-host.example/2EBE702A97D6’ 
id=’ B3C17F7B-B9EF-4ABA-B08D-805DA9F34626’ > 
<query xmlns=’http://jabber.org/protocol/disco#items’ > 
<item node=’ NEA1’ 
name=' Endpoint Posture Information’ 
jid=’broker.security-grid.example’ /> 
<item node=’MILEHost’ 
name=' MILE Host Data’ 
jid=’broker.security-grid.example’ /> 
</query> 
</igq> 


In order to determine the exact nature of each Topic (i.e., in order 
to find Topics that publish incidents in the IODEF format), a 
Platform would send an XMPP "disco#info" request to each Topic: 


<iq type=’ get’ 
from=’ xmpp-grid-client@mile-host.example/2EBE702A97D6’ 
to='’broker.security-grid.example’ 
id=’ D367D4ED-2795-48 9C-A8 3E-EAAFA07A0356’ > 
<query xmlns=’http://jabber.org/protocol/disco#info’ 
node=' MILEHost’ /> 
</iq> 
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The Broker responds with the "disco#info" description, which MUST 
include an XMPP data form [XEP-0004] with a 'pubsub#type' field that 
specifies the supported namespace (in this example, the IODEF 
namespace defined in [RFC7970]): 


<iq type=’ result’ 

from=’broker.security-grid.example’ 

to=’ xmpp-grid-client@mile-host.example/2EBE702A97D6’ 

id=’ D367D4ED-2795-48 9C-A8 3E-EAAFA07A0356’ > 

<query xmlns=’http://jabber.org/protocol/disco#info’ 

node=’ MILEHost’ > 

<identity category=’ pubsub’ type=’ leaf’ /> 

<feature var='http://jabber.org/protocol/pubsub’ /> 

<x xmlns=' jabber:x:data’ type=’ result’> 

<field var=’FORM_TYPE’ type=’hidden’> 
<value>http://jabber.org/protocol/pubsub#meta-data</value> 

</field> 

<field var=’pubsub#type’ label=’Payload type’ type=’text-single’> 
<value>urn:ietf:params:xml:ns:iodef-2.0</value> 

</field> 


</query> 
</igq> 


The Platform discovers the Topics by obtaining the Broker’s response 
and obtaining the namespaces returned in the "pubsub#type" field (in 
the foregoing example, IODEF 2.0). 


6. Publish-Subscribe 


Using the XMPP publish-subscribe extension [XEP-0060], a Consumer 
subscribes to a Topic, and a Provider publishes information to that 
Topic, which the Broker then distributes to all subscribed Consumers. 


First, a Provider would create a Topic as follows: 


<iq type=’set’ 
from=’ datasource@provider.example/F12C2EFC9BBO’ 
to=’broker.security-grid.example’ 
id=’ A67507DF-2F22-4937-8D30-88D2F7DBA279’ > 
<pubsub xmlns='’http://jabber.org/protocol/pubsub’ > 
<create node=’MILEHost’ /> 
</pubsub> 
</iq> 


Note: The foregoing example is the minimum protocol needed to create 
a Topic with the default node configuration on the XMPP publish- 
subscribe service specified in the 'to' address of the creation 
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request stanza. Depending on security requirements, the Provider 
might need to request a non-default configuration for the node; see 
[XEP-0060] for detailed examples. To also help with the Topic 
configuration, the Provider may also optionally include configuration 
parameters such as: 


<configure> 
<x xmlns=' jabber:x:data’ type=' submit'> 


<field var=' FORM TYPE' type='hidden'> 
<value>http://jabber.org/protocol/pubsub#node_config</value> 

</field> 

<field var=' pubsub#access_model'><value>authorize</value></field> 

<field var=' pubsub#persist_items’ ><value>1</value></field> 

<field var=’ pubsub#send_last_published_item’ > 
<value>never</value> 

</field> 

</x> 
</configure> 


The above configuration indicates the Topic is configured so that the 
Broker will a) explicitly approve subscription requests, b) 
persistently store all messages posted to the Topic, and c) not 
deliver the most recently published when an entity initially 
subscribes to the Topic. Please refer to [XEP-0060] for a more 


detailed 


description of this configuration and other available 


configuration options. 


Unless an error occurs (see [XEP-0060] for various error flows), the 
Broker responds with success: 


<iq type=’ result’ 
from=’broker.security-grid.example’ 
to=’ datasource@provider.example/F12C2EFC9BBO’ 
id=’ A67507DF-2F22-4937-8D30-88D2F7DBA279" /> 


Second, a Consumer would subscribe as follows: 


<iq type=’set’ 
from=’ xmpp-grid-client@mile-host.example/2EBE702A97D6’ 


to=’broker.security-grid.example’ 


id=’ 9C6EEE9YE-F09A-4418-8D68-3BA6AF 852522’ > 
<pubsub xmlns='’http://jabber.org/protocol/pubsub’ > 
<subscribe node=’MILEHost’ 


jid=’ xmpp-grid-client@mile-host.example’ /> 


</pubsub> 
</iq> 
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Unless an error occurs (see [XEP-0060] for various error flows), the 
Broker makes an appropriate authorization decision. If access is 
granted, it responds with success: 


<iq type=' result' 
from=' broker.security-grid.example' 
to=’ xmpp-grid-client@mile-host.example/2EBE702A97D6" 
id=’ 9C6EEE9E-F09A-4418-8D68-3BA6AF852522'> 
<pubsub xmlns='http://jabber.org/protocol/pubsub' > 
<subscription 
node=' MILEHost' 
jid=’ xmpp-grid-client@mile-host.example’ 
subscription=’ subscribed’ /> 
</pubsub> 
</iq> 


Third, a Provider would publish an incident to the Broker using the 
MILEHost Topic as follows: 


<iq type=’ set’ 
from=’ datasource@provider.example/F12C2EFC9BBO’ 
to=’broker.security-grid.example’ 
id=’ 2A17D283-0DAE-4A6C-85A9-C10B1B40928C’ > 
<pubsub xmlns='’http://jabber.org/protocol/pubsub’ > 
<publish node=’MILEHost’ > 
<item id=’ 8bh1ig27skbga47f£h9wk7’ > 
<IODEF-—Document version="2.00" xml:lang="en" 
xmlins="urn:ietf:params:xml:ns:iodef-2.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation= 
"http://www.iana.org/assignments/xml-registry/ 
schema/iodef-2.0.xsd"> 
<Incident purpose="reporting" restriction="private"> 
<IncidentID name="csirt.example.com">492382</IncidentID> 
<GenerationTime>2015-07-18T09:00:00-05:00</GenerationTime> 
<Contact type="organization" role="creator"> 
<Email> 
<EmailTo>contact@csirt.example.com</EmailTo> 
</Email> 
</Contact> 
</Incident> 
</IODEF-Document> 
</item> 
</publish> 
</pubsub> 
</iq> 
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(The payload in the foregoing example is from [RFC7970]; payloads for 
additional use cases can be found in [RFC8274].) 


The Broker would then deliver that incident report to all Consumers 
who are subscribed to the Topic: 


<message 
from=' broker.security-grid.example' 
to=’ xmpp-grid-client@mile-host.example/2EBE702A97D6’ 
id=’ 37B3921D-4F7F-450F-A589-56119A88BC2E’ > 
<event xmlns=’http://jabber.org/protocol/pubsub#event’ > 
<items node=’MILEHost’> 
<item id=’ iah37s61s964gquqy47aksbx9453ks77'> 
<IODEF-—Document version="2.00" xml:lang="en" 
xmlns="urn:ietf:params:xml:ns:iodef-2.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation= 
"http://www.iana.org/assignments/xml-registry/ 
schema/iodef-2.0.xsd"> 
<Incident purpose="reporting" restriction="private"> 
<IncidentID name="csirt.example.com">492382</IncidentID> 
<GenerationTime>2015-07-18T09:00:00-05:00</GenerationTime> 
<Contact type="organization" role="creator"> 
<Email> 
<EmailTo>contact@csirt.example.com</EmailTo> 
</Email> 
</Contact> 
</Incident> 
</IODEF-Document> 
</item> 
</items> 
</event> 
</message> 


Note that [XEP-0060] uses the XMPP "<message />" stanza for delivery 
of content. To ensure that messages are delivered to the Consumer 
even if the Consumer is not online at the same time that the 
Publisher generates the message, an XMPP-Grid Controller MUST support 
"offline messaging" delivery semantics as specified in [RFC6121], the 
best practices of which are further explained in [XEP-0160]. 


7. IANA Considerations 


This document has no actions for IANA. 


Cam-Winget, et al. Standards Track [Page 13] 


RFC 8600 XMPP Grid June 2019 


8. Security Considerations 


An XMPP-Grid Controller serves as a controlling broker for XMPP-Grid 
Platforms such as enforcement points, policy servers, Configuration 
Management Databases (CMDBs), and sensors, using a publish-subscribe- 
search model of information exchange and lookup. By increasing the 
ability of XMPP-Grid Platforms to learn about and respond to security 
incident reports and other security-relevant information, XMPP-Grid 
can improve the timeliness and utility of the security system. 
However, this integrated security system can also be exploited by 
attackers if they can compromise it. Therefore, strong security 
protections for XMPP-Grid are essential. 


As XMPP is the core of this document, the security considerations of 
[RFC6120] apply. In addition, as XMPP-Grid defines a specific 
instance, this section provides a security analysis of the XMPP-Grid 
data transfer protocol and the architectural elements that employ it, 
specifically with respect to their use of this protocol. Three 
subsections define the trust model (which elements are trusted to do 
what), the threat model (attacks that can be mounted on the system), 
and the countermeasures (ways to address or mitigate the threats 
previously identified). 


8.1. Trust Model 


The first step in analyzing the security of the XMPP-Grid transport 
protocol is to describe the trust model and list what each 
architectural element is trusted to do. The items listed here are 
assumptions, but provisions are made in "Threat Model" (Section 8.2) 
and "Countermeasures" (Section 8.3) for elements that fail to perform 
as they were trusted to do. 


8.1.1. Network 


The network used to carry XMPP-Grid messages (i.e., the underlying 
network transport layer over which XMPP runs) is trusted to: 


o Perform best-effort delivery of network traffic 


The network used to carry XMPP-Grid messages is not expected 
(trusted) to: 


o Provide confidentiality or integrity protection for messages sent 
over it 


o Provide timely or reliable service 
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8.1 


22s 


XMPP-Grid Platforms 


Authorized XMPP-Grid Platforms are trusted to: 


[e] 


8 L. 


3. 


Preserve the confidentiality of sensitive data retrieved via the 
XMPP-Grid Controller 


XMPP-Grid Controller 


The XMPP-Grid Controller (including its associated Broker) is trusted 


box 


[e] 


Broker requests for data and enforce authorization of access to 
this data throughout its lifecycle 


Perform service requests in a timely and accurate manner 
Create and maintain accurate operational attributes 


Only reveal data to and accept service requests from authorized 
parties 


Preserve the integrity (and confidentiality against unauthorized 
parties) of the data flowing through it. 


The XMPP-Grid Controller is not expected (trusted) to: 


[e] 


8. L; 


4. 


Verify the truth (correctness) of data 


Certification Authority 


To allow XMPP-Grid Platforms to mutually authenticate with XMPP-Grid 


Controllers, it is expected that a Certification Authority (CA) is 
employed to issue certificates. Such a CA (or each CA, if there are 
several) is trusted to: 

o Ensure that only proper certificates are issued and that all 


certificates are issued in accordance with the CA’s policies 
Revoke certificates previously issued when necessary 


Regularly and securely distribute certificate revocation 
information 


Promptly detect and report any violations of this trust so that 
they can be handled 


Cam-Winget, et al. Standards Track [Page 15] 


RFC 8600 XMPP Grid June 2019 


The CA is not expected (trusted) to: 


o Issue certificates that go beyond the XMPP-Grid needs or other 
constraints imposed by a relying party. 


8.2. Threat Model 


To secure the XMPP-Grid data transfer protocol and the architectural 
elements that implement it, this section identifies the attacks that 
can be mounted against the protocol and elements. 


8.2.1. Network Attacks 


A variety of attacks can be mounted using the network. For the 
purposes of this subsection, the phrase "network traffic" can be 
taken to mean messages and/or parts of messages. Any of these 
attacks can be mounted by network elements, by parties who control 
network elements, and (in many cases) by parties who control network- 
attached devices. 


o Network traffic can be passively monitored to glean information 
from any unencrypted traffic 


o Even if all traffic is encrypted, valuable information can be 
gained by traffic analysis (volume, timing, source and destination 
addresses, etc.) 


o Network traffic can be modified in transit 

o Previously transmitted network traffic can be replayed 

o New network traffic can be added 

o Network traffic can be blocked, perhaps selectively 

o A man-in-the-middle (MITM) attack can be mounted where an attacker 


interposes itself between two communicating parties and 
impersonates the other end to either or both parties 


o Undesired network traffic can be sent in an effort to overload an 
architectural component, thus mounting a denial-of-service attack 


8.2.2. XMPP-Grid Platforms 


An unauthorized XMPP-Grid Platform (one that is not recognized by the 
XMPP-Grid Controller or is recognized but not authorized to perform 
any actions) cannot mount any attacks other than those listed in 
"Network Attacks" (Section 8.2.1). 
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An authorized XMPP-Grid Platform, on the other hand, can mount many 
attacks. These attacks might occur because the XMPP-Grid Platform is 
controlled by a malicious, careless, or incompetent party (whether 
because its owner is malicious, careless, or incompetent or because 
the XMPP-Grid Platform has been compromised and is now controlled by 
a party other than its owner). They might also occur because the 
XMPP-Grid Platform is running malicious software, the XMPP-Grid 
Platform is running buggy software (which can fail in a state that 
floods the network with traffic), or the XMPP-Grid Platform has been 
configured improperly. From a security standpoint, it generally 
makes no difference why an attack is initiated. The same 
countermeasures can be employed in any case. 


Here is a list of attacks that can be mounted by an authorized XMPP- 
Grid Platform: 


o Cause many false alarms or otherwise overload the XMPP-Grid 
Controller or other elements in the network security system 
(including human administrators), leading to a denial of service 
or parts of the network security system being disabled. 


o Omit important actions (such as posting incriminating data), 
resulting in incorrect access. 


o Use confidential information obtained from the XMPP-Grid 
Controller to enable further attacks (such as using endpoint 
health check results to exploit vulnerable endpoints). 


o Advertise data crafted to exploit vulnerabilities in the XMPP-Grid 
Controller or in other XMPP-Grid Platforms with the goal of 
compromising those systems. 


o Issue a search request or set up a subscription that matches an 
enormous result, leading to resource exhaustion on the XMPP-Grid 
Controller, the publishing XMPP-Grid Platform, and/or the network. 


o Establish a communication channel using another XMPP-Grid 
Platform’s session-id. 


o Advertise false data that leads to incorrect (e.g., potentially 
attacker-controlled or -induced) behavior of XMPP-Grid Platforms 
by virtue of applying correct procedures to the falsified input. 


Dependencies or vulnerabilities of authorized XMPP-Grid Platforms can 
be exploited to effect these attacks. Another way to effect these 
attacks is to gain the ability to impersonate an XMPP-Grid Platform 
(through theft of the XMPP-Grid Platform’s identity credentials or 
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through other means). Even a clock skew between the XMPP-Grid 
Platform and XMPP-Grid Controller can cause problems if the XMPP-Grid 
Platform assumes that old XMPP-Grid Platform data should be ignored. 


3. XMPP-Grid Controllers 


An unauthorized XMPP-Grid Controller (one that is not trusted by 
XMPP-Grid Platforms) cannot mount any attacks other than those listed 
in "Network Attacks" (Section 8.2.1). 


An authorized XMPP-Grid Controller can mount many attacks. Similar 
to the XMPP-Grid Platform case described above, these attacks might 
occur because the XMPP-Grid Controller is controlled by a malicious, 
careless, or incompetent party (either an XMPP-Grid Controller 
administrator or an attacker who has seized control of the XMPP-Grid 
Controller). They might also occur because the XMPP-Grid Controller 
is running malicious software, the XMPP-Grid Controller is running 
buggy software (which can fail in a state that corrupts data or 
floods the network with traffic), or the XMPP-Grid Controller has 
been configured improperly. 


All of the attacks listed for XMPP-Grid Platform above can be mounted 
by the XMPP-Grid Controller. Detection of these attacks will be more 
difficult since the XMPP-Grid Controller can create false operational 
attributes and/or logs that imply some other party created any bad 
data. 


Additional XMPP-Grid Controller attacks can include: 


o Exposing different data to different XMPP-Grid Platforms to 
mislead investigators or cause inconsistent behavior. 


o Mounting an even more effective denial-of-service attack than a 
single XMPP-Grid Platform could; some mechanisms include inducing 
many platforms to perform the same operation in an amplification- 
style attack, completely refusing to pass any traffic at all, or 
sending floods of traffic to (certain) platforms or other targets. 


o Obtaining and caching XMPP-Grid Platform credentials so they can 
be used to impersonate XMPP-Grid Platforms even after a breach of 
the XMPP-Grid Controller is repaired. Some Simple Authentication 
and Security Layer (SASL) mechanisms (including the mandatory-to- 
implement SCRAM and EXTERNAL with TLS mutual certificate-based 
authentication) do not admit this class of attack, but others 
(such as PLAIN) are susceptible. 
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Obtaining and caching XMPP-Grid Controller administrator 
credentials so they can be used to regain control of the XMPP-Grid 
Controller after the breach of the XMPP-Grid Controller is 
repaired. 


Eavesdropping, injecting, or modifying the data being transferred 
between Provider and Consumer. 


Dependencies or vulnerabilities of the XMPP-Grid Controller can be 
exploited to obtain control of the XMPP-Grid Controller and effect 
these attacks. 


8.2. 


Certification Authority 


A Certification Authority trusted to issue certificates for the XMPP- 
Grid Controller and/or XMPP-Grid Platforms can mount several attacks: 


[e] 


Issue certificates for unauthorized parties, enabling them to 
impersonate authorized parties such as the XMPP-Grid Controller or 
an XMPP-Grid Platform. This can lead to all the threats that can 
be mounted by the certificate's subject. 


Issue certificates without following all of the CA’s policies. 
Because this can result in issuing certificates that can be used 
to impersonate authorized parties, this can lead to all the 
threats that can be mounted by the certificate’s subject. 


Fail to revoke previously issued certificates that need to be 
revoked. This can lead to undetected impersonation of the 
certificate’s subject or failure to revoke authorization of the 
subject and therefore can lead to all of the threats that can be 
mounted by that subject. 


Fail to regularly and securely distribute certificate revocation 
information. This can cause a relying party to accept a revoked 
certificate, leading to undetected impersonation of the 
certificate’s subject or failure to revoke authorization of the 
subject and therefore can lead to all of the threats that can be 
mounted by that subject. It can also cause a relying party to 
refuse to proceed with a transaction because timely revocation 
information is not available, even though the transaction should 
be permitted to proceed. 


Allow the CA’s private key to be revealed to an unauthorized 
party. This can lead to all the threats above. Even worse, the 
actions taken with the private key will not be known to the CA. 
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o Fail to promptly detect and report errors and violations of trust 
so that relying parties can be promptly notified. This can cause 
the threats listed earlier in this section to persist longer than 
necessary, leading to many knock-on effects. 


8.3. Countermeasures 


Below are countermeasures for specific attack scenarios to the XMPP- 
Grid infrastructure. 


8.3.1. Securing the XMPP-Grid Data Transfer Protocol 


To address network attacks, the XMPP-Grid data transfer protocol 
described in this document requires that the XMPP-Grid messages MUST 
be carried over TLS (minimally TLS 1.2 and preferably TLS 1.3 
[RFC8446]) as described in [RFC6120] and updated by [RFC7590]. The 
XMPP-Grid Controller and XMPP-Grid Platforms SHOULD mutually 
authenticate. The XMPP-Grid Platform MUST verify the XMPP-Grid 
Controller’s certificate and determine whether the XMPP-Grid 
Controller is trusted by this XMPP-Grid Platform before completing 
the TLS handshake. To ensure interoperability, implementations MUST 
implement at least either the SASL EXTERNAL mechanism [RFC4422] or 
the SASL SCRAM mechanism. When using the SASL SCRAM mechanism, the 
SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 
variant, and SHA-256 variants [RFC7677] SHOULD be preferred over 
SHA-1 variants [RFC5802]). XMPP-Grid Platforms and XMPP-Grid 
Controllers using certificate-based authentication SHOULD each verify 
the revocation status of the other party's certificate. The 
selection of the XMPP-Grid Platform authentication technique to use 
in any particular deployment is left to the administrator. 


These protocol security measures provide protection against all the 
network attacks listed in Section 8.2 except denial-of-service 
attacks. If protection against these denial-of-service attacks is 
desired, ingress filtering, rate limiting per source IP address, and 
other denial-of-service mitigation measures can be employed. In 
addition, an XMPP-Grid Controller MAY automatically disable a 
misbehaving XMPP-Grid Platform. 


8.3.2. Securing XMPP-Grid Platforms 


XMPP-Grid Platforms can be deployed in locations that are susceptible 
to physical attacks. Physical security measures can be taken to 
avoid compromise of XMPP-Grid Platforms, but these are not always 
practical or completely effective. An alternative measure is to 
configure the XMPP-Grid Controller to provide read-only access for 
such systems. The XMPP-Grid Controller SHOULD also include a full 
authorization model so that individual XMPP-Grid Platforms can be 
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configured to have only the privileges that they need. The XMPP-Grid 
Controller MAY provide functional templates so that the administrator 
can configure a specific XMPP-Grid Platform as a DHCP [RFC2131] 
server and authorize only the operations and metadata types needed by 
a DHCP server to be permitted for that XMPP-Grid Platform. These 
techniques can reduce the negative impacts of a compromised XMPP-Grid 
Platform without diminishing the utility of the overall system. 


To handle attacks within the bounds of this authorization model, the 
XMPP-Grid Controller MAY also include rate limits and alerts for 
unusual XMPP-Grid Platform behavior. XMPP-Grid Controllers SHOULD 
make it easy to revoke an XMPP-Grid Platform's authorization when 
necessary. The XMPP-Grid Controller SHOULD include auditable logs of 
XMPP-Grid Platform activities. 


To avoid compromise of XMPP-Grid Platforms, they SHOULD be hardened 
against attack and minimized to reduce their attack surface. They 
should be well managed to minimize vulnerabilities in the underlying 
platform and in systems upon which the XMPP-Grid Platform depends. 
Personnel with administrative access should be carefully screened and 
monitored to detect problems as soon as possible. 


8.3.3. Securing XMPP-Grid Controllers 


Because of the serious consequences of XMPP-Grid Controller 
compromise, XMPP-Grid Controllers need to be especially well hardened 
against attack and minimized to reduce their attack surface. They 
need to be well managed to minimize vulnerabilities in the underlying 
platform and in systems upon which the XMPP-Grid Controller depends. 
Network security measures such as firewalls or intrusion detection 
systems can be used to monitor and limit traffic to and from the 
XMPP-Grid Controller. Personnel with administrative access ought to 
be carefully screened and monitored to detect problems as soon as 
possible. Administrators SHOULD NOT use password-based 
authentication but SHOULD instead use non-reusable credentials and 
multi-factor authentication (where available). Physical security 
measures ought to be employed to prevent physical attacks on XMPP- 
Grid Controllers. 


To ease detection of XMPP-Grid Controller compromise should it occur, 
XMPP-Grid Controller behavior should be monitored to detect unusual 
behavior (such as a reboot, a large increase in traffic, or different 
views of an information repository for similar XMPP-Grid Platforms). 
It is a matter of local policy whether XMPP-Grid Platforms log and/or 
notify administrators when peculiar XMPP-Grid Controller behavior is 
detected and whether read-only audit logs of security-relevant 
information (especially administrative actions) are maintained; 
however, such behavior is encouraged to aid in forensic analysis. 
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Furthermore, if compromise of an XMPP-Grid Controller is detected, a 
careful analysis should be performed, and any reusable credentials 
that could have been compromised should be reissued. 


To address the potential for the XMPP-Grid Controller to eavesdrop, 
modify or inject data, it would be desirable to deploy end-to-end 
encryption between the Provider and the Consumer(s). Unfortunately, 
because there is no standardized method for encryption of one-to-many 
messages within XMPP, techniques for enforcing end-to-end encryption 
are out of scope for this specification. 


8.3.4. Broker Access Models for Topics 


The XMPP publish-subscribe specification [XEP-0060] defines five 
access models for subscribing to Topics at a Broker: open, presence, 


roster, authorize, and whitelist. The first model allows 
uncontrolled access, and the next two models are appropriate only in 
instant-messaging applications. Therefore, a Broker SHOULD support 


only the authorize model (under which the Topic owner needs to 
approve all subscription requests and only subscribers can retrieve 
data items) and the whitelist model (under which only preconfigured 
Platforms can subscribe or retrieve data items). In order to ease 
the deployment burden, subscription approvals and whitelist 
management can be automated (e.g., the Topic "owner" can be a policy 
server). The choice between "authorize" and "whitelist" as the 
default access model is a matter for local service policy. 


8.3.5. Limit on Search Result Size 


While XMPP-Grid is designed for high scalability to hundreds of 
thousands of Platforms, an XMPP-Grid Controller MAY establish a limit 
to the amount of data it is willing to return in search or 
subscription results. Platforms could use [XEP-0059] to restrict the 
size of the result sets the Controller returns in search or 
subscription results or topics' service discovery. This mitigates 
the threat of an XMPP-Grid Platform causing resource exhaustion by 
issuing a search or subscription that leads to an enormous result. 


8.3.6. Securing the Certification Authority 


As noted above, compromise of a Certification Authority (CA) trusted 
to issue certificates for the XMPP-Grid Controller and/or XMPP-Grid 
Platforms is a major security breach. Many guidelines for proper CA 
security have been developed: the CA/Browser Forum's Baseline 
Requirements, the American Institute of Certified Public Accountants 
(AICPA) / Canadian Institute of Chartered Accountants (CICA) Trust 
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Service Principles, the IETF’s Certificate Transparency [RFC6962], 
etc. The CA operator and relying parties should agree on 
appropriately rigorous security practices to be used. 


Even with the most rigorous security practices, a CA can be 
compromised. If this compromise is detected quickly, relying parties 
can remove the CA from their list of trusted CAs, and other CAs can 
revoke any certificates issued to the CA. However, CA compromise may 
go undetected for some time, and there's always the possibility that 
a CA is being operated improperly or in a manner that is not in the 
interests of the relying parties. For this reason, relying parties 
may wish to "pin" a small number of particularly critical 
certificates (such as the certificate for the XMPP-Grid Controller). 
Once a certificate has been pinned, the relying party will not accept 
another certificate in its place unless the Administrator explicitly 
commands it to do so. This does not mean that the relying party will 
not check the revocation status of pinned certificates. However, the 
Administrator can still be consulted if a pinned certificate is 
revoked, since the CA and revocation process are not completely 
trusted. By "pinning" one or a small set of certificates, the 
relying party has identified the effective XMPP-Grid Controller (s) 
authorized for connection. 


8.3.7. End-to-End Encryption of Messages 


Because it is expected that there will be a relatively large number 
of Consumers for every Topic, for the purposes of content discovery 
and scaling, this document specifies a "one-to-many" communications 
pattern using the XMPP Publish-Subscribe extension. Unfortunately, 
there is no standardized technology for end-to-end encryption of one- 
to-many messages in XMPP. This implies that messages can be subject 
to eavesdropping, data injection, and data modification attacks 
within a Broker or Controller. If it is necessary to mitigate 
against such attacks, implementers would need to select a messaging 
pattern other than [XEP-0060], most likely the basic "instant 
messaging" pattern specified in [RFC6121] with a suitable XMPP 
extension for end-to-end encryption. The description of such an 
approach is out of scope for this document. 


8.4. Summary 


XMPP-Grid’s considerable value as a broker for security-sensitive 
data exchange distribution also makes the protocol and the network 
security elements that implement it a target for attack. Therefore, 
strong security has been included as a basic design principle within 
the XMPP-Grid design process. 
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The XMPP-Grid data transfer protocol provides strong protection 
against a variety of different attacks. In the event that an XMPP- 
Grid Platform or XMPP-Grid Controller is compromised, the effects of 
this compromise are reduced and limited with the recommended role- 
based authorization model and other provisions, and best practices 
for managing and protecting XMPP-Grid systems have been described. 
Taken together, these measures should provide protection commensurate 
with the threat to XMPP-Grid systems, thus ensuring that they fulfill 
their promise as a network security clearinghouse. 


9. Privacy Considerations 


XMPP-Grid Platforms can publish information about endpoint health, 
network access, events (which can include information about which 
services an endpoint is accessing), roles and capabilities, and the 
identity of th nd user operating the endpoint. Any of this 
published information can be queried by other XMPP-Grid Platforms and 
could potentially be used to correlate network activity to a 
particular end user. 


Dynamic and static information brokered by an XMPP-Grid Controller, 
ostensibly for the purposes of correlation by XMPP-Grid Platforms for 
intrusion detection, could be misused by a broader set of XMPP-Grid 
Platforms that hitherto have been performing specific roles with a 
strict, well-defined separation of duties. 


Care needs to be taken by deployers of XMPP-Grid to ensure that the 
information published by XMPP-Grid Platforms does not violate 
agreements with end users or local and regional laws and regulations. 
This can be accomplished either by configuring XMPP-Grid Platforms to 
not publish certain information or by restricting access to sensitive 
data to trusted XMPP-Grid Platforms. That is, the easiest means to 
ensure privacy or protect sensitive data is to omit or not share it 
at all. 


Similarly, care must be taken by deployers and XMPP-Grid Controller 
implementations as they implement the appropriate auditing tools. In 
particular, any information, such as logs, must be sensitive to the 
type of information stored to ensure that the information does not 
violate privacy and agreements with end users or local and regional 
laws and regulations. 


Another consideration for deployers is to enable end-to-end 
encryption to ensure the data is protected while in transit between 
data layers and thus protected from the transport layer. The means 
to achieve end-to-end encryption is beyond the scope of this 
document. 
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10. Operations and Management Considerations 


In order to facilitate the management of Providers and the onboarding 
of Consumers, it is helpful to generate the following ahead of time: 


o Agreement between the operators of Provider services and the 
implementers of Consumer software regarding identifiers for common 
Topics (e.g., these could be registered with the XMPP Software 
Foundation's registry of well-known nodes for service discovery 
and publish-subscribe, located at <https://xmpp.org/registrar/ 
nodes.html>). 


o Security certificates (including appropriate certificate chains) 
for Controllers, including identification of any Providers 
associated with the Controllers (which might be located at 
subdomains). 


o Consistent and secure access control policies for publishing and 
subscribing to Topics. 


These matters are out of scope for this document but ought to be 
addressed by the XMPP-Grid community. 
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